Re: sql in php with paging -- WEB400

Subject: Re: sql in php with paging
From: Nathan Andelin <nandelin@xxxxxxxxx>
Date: Tue, 21 Oct 2008 14:44:38 -0700 (PDT)
List-archive: <http://archive.midrange.com/web400>
List-help: <mailto:web400-request@midrange.com?subject=help>
List-id: Web Enabling the AS400 / iSeries <web400.midrange.com>
List-post: <mailto:web400@midrange.com>
List-subscribe: <http://lists.midrange.com/mailman/listinfo/web400>, <mailto:web400-request@midrange.com?subject=subscribe>
List-unsubscribe: <http://lists.midrange.com/mailman/listinfo/web400>, <mailto:web400-request@midrange.com?subject=unsubscribe>

From: Walden H. Leverich
Been a while since I looked at the system limits documentation, but I'd
think you'd need a decent sized i to handle 50K active jobs ...

I think we're getting to the heart of the matter. Open connections (active jobs) use system resources. On the other hand, rerunning SQL statements and saving and restoring state with each request uses system resources too. The former is memory intensive while the latter is CPU intensive. So which constraint is going to be more problematic?

Say it takes an extra 25 milliseconds of CPU time to rerun an SQL statement and save and restore state. Say 50,000 users are making requests at 10 second intervals. That would mean 5,000 requests per second. You'd probably need about 15 additional cpu's just for the extra workload.

I see trade-off's either way.

Nathan.

As an Amazon Associate we earn from qualifying purchases.

Follow-Ups:

Re: sql in php with paging , Walden H. Leverich

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.