Comparison with long-running servers (Node.js) in PHP - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a key difference between PHP and Node.js in how they handle server requests?

PHP creates a new process for each request, while Node.js runs a single long-running process that handles many requests asynchronously.

intermediate

Why does Node.js use an event-driven model for handling requests?

Node.js uses an event-driven model to efficiently handle many requests without waiting for each to finish, improving performance for I/O tasks.

intermediate

How does PHP's request lifecycle affect memory usage compared to Node.js?

PHP frees memory after each request ends because it starts fresh every time, while Node.js keeps memory in use as it runs continuously.

beginner

What is one advantage of PHP's short-lived process model?

It isolates each request, so errors or memory leaks in one request do not affect others.

intermediate

What challenge might arise from Node.js's long-running server approach?

Memory leaks or bugs can accumulate over time since the server process stays alive, requiring careful management.

How does PHP handle each incoming web request?

A Uses a single long-running process

B Starts a new process for each request

C Handles requests asynchronously in one process

D Queues requests and processes them one by one

PHP starts a new process for each request, unlike Node.js which uses a single long-running process.

What is a benefit of Node.js's event-driven model?

A It handles many requests efficiently without waiting

B It blocks other requests until one finishes

C It creates a new process for each request

D It uses more memory per request

Node.js handles many requests efficiently by not waiting for each to finish, thanks to its event-driven model.

Which server model isolates errors per request better?

A Node.js long-running process

B Both are equal

C Neither isolates errors

D PHP short-lived process

PHP's short-lived process model isolates errors per request, preventing one request's error from affecting others.

What is a potential downside of Node.js's long-running server?

A It restarts after every request

B It uses less memory overall

C It can accumulate memory leaks over time

D It cannot handle asynchronous tasks

Because Node.js runs continuously, memory leaks or bugs can build up if not managed properly.

Which technology is more likely to free memory after each request?

A PHP

B Neither frees memory

C Both free memory continuously

D Node.js

PHP frees memory after each request because it starts a new process every time.

Explain how PHP and Node.js differ in handling web server requests and the impact on memory management.

Think about how each handles requests and what happens to memory after.

Describe one advantage and one challenge of using a long-running server like Node.js compared to PHP's model.

Consider performance and maintenance aspects.

Practice

1. Which statement best describes how PHP handles variables compared to Node.js in a web server context?

easy

A. PHP keeps variables in memory between requests, but Node.js resets them every time.

B. Both PHP and Node.js reset variables on every request.

C. PHP resets variables on every request, while Node.js keeps variables in memory between requests.

D. Both PHP and Node.js keep variables in memory between requests.

Solution

1. Step 1: Understand PHP's request model

   PHP scripts start fresh on each request, so all variables are reset.

2. Step 2: Understand Node.js server behavior

   Node.js servers run continuously, so variables can persist in memory across requests.

3. Final Answer:

   PHP resets variables on every request, while Node.js keeps variables in memory between requests. -> Option C

4. Quick Check:

   PHP resets, Node.js persists [OK]

Hint: Remember PHP restarts each request; Node.js runs continuously [OK]

Common Mistakes:

• Thinking PHP keeps variables in memory between requests
• Assuming Node.js resets variables like PHP
• Confusing session storage with variable persistence

2. Which of the following PHP code snippets correctly starts a session to preserve data across requests?

easy

A.

B.

C.

D.

Solution

1. Step 1: Identify the correct PHP function to start a session

   The correct function is session_start() to begin or resume a session.

2. Step 2: Check the code syntax

   uses session_start() correctly; others use invalid function names.

3. Final Answer:

   <?php session_start(); $_SESSION['count'] = 1; ?> -> Option A

4. Quick Check:

   Use session_start() to begin sessions [OK]

Hint: Use session_start() exactly to enable sessions [OK]

Common Mistakes:

• Using incorrect function names like start_session()
• Forgetting to call session_start() before using $_SESSION
• Assuming sessions start automatically

3. Consider this PHP code snippet run on two separate requests:

<?php
session_start();
if (!isset($_SESSION['visits'])) {
    $_SESSION['visits'] = 1;
} else {
    $_SESSION['visits']++;
}
echo $_SESSION['visits'];
?>

What will be the output on the second request?

medium

A. 1

B. 2

C. 0

D. Error

Solution

1. Step 1: Analyze session variable initialization

   On the first request, $_SESSION['visits'] is not set, so it is initialized to 1.

2. Step 2: Analyze second request behavior

   On the second request, $_SESSION['visits'] exists, so it increments by 1, becoming 2.

3. Final Answer:

   2 -> Option B

4. Quick Check:

   Session increments visits count correctly [OK]

Hint: Sessions keep data; visits count increases each request [OK]

Common Mistakes:

• Assuming visits resets to 1 every request
• Forgetting to call session_start()
• Expecting an error due to undefined index

4. This PHP script is intended to count visits using sessions, but it always outputs 1 on every request:

<?php
if (!isset($_SESSION['count'])) {
    $_SESSION['count'] = 1;
} else {
    $_SESSION['count']++;
}
echo $_SESSION['count'];
?>

What is the most likely cause of this problem?

medium

A. The session_start() function is missing, so sessions don't work.

B. The $_SESSION variable is overwritten elsewhere in the code.

C. The $_SESSION['count'] variable is reset manually each time.

D. The echo statement is inside the else block only.

Solution

1. Step 1: Check for session initialization

   The code does not call session_start(), so PHP does not load or save session data.

2. Step 2: Understand session behavior without session_start()

   Without starting the session, $_SESSION is empty each request, so count resets to 1 every time.

3. Final Answer:

   The session_start() function is missing, so sessions don't work. -> Option A

4. Quick Check:

   Always call session_start() before using $_SESSION [OK]

Hint: Always start session with session_start() to keep data [OK]

Common Mistakes:

• Assuming $_SESSION works without session_start()
• Thinking variable reset is due to manual code
• Ignoring session initialization step

5. You want to simulate a long-running server behavior in PHP to keep a counter in memory across multiple requests without using sessions or databases. Which approach is the best to achieve this?

hard

A. Restart the PHP server after each request to reset variables.

B. Store the counter in a local variable inside a PHP script executed per request.

C. Use cookies to store the counter on the client side only.

D. Use a PHP daemon script running continuously and communicate via sockets or shared memory.

Solution

1. Step 1: Understand PHP's request lifecycle

   PHP scripts run fresh on each request, so local variables reset automatically.

2. Step 2: Identify how to keep data in memory across requests

   To keep data in memory like Node.js, PHP must run as a long-running process (daemon) and communicate externally.

3. Step 3: Evaluate options

   Use a PHP daemon script running continuously and communicate via sockets or shared memory. describes running a PHP daemon with sockets/shared memory, which simulates long-running server behavior.

4. Final Answer:

   Use a PHP daemon script running continuously and communicate via sockets or shared memory. -> Option D

5. Quick Check:

   Long-running PHP needs daemon + IPC, not per-request scripts [OK]

Hint: Run PHP as daemon with IPC to keep data in memory [OK]

Common Mistakes:

• Thinking local variables persist across requests
• Confusing cookies with server memory
• Restarting server resets all variables